(レポート) ISM304: OracleからAmazonRDS MySQLまたはAmazon Auroraへの移行：Gullup社の事例

Developers.IO 2015

#イベントレポート

#ソリューション

#Amazon Aurora

#Amazon RDS

#MySQL

hanse

2015.10.25

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。オペ部の半瀬です。

はじめに

今回もAWS re:Invent 2015 のセッションレポートです。（コチラでレベルごとのセッション一覧をひっぱれます。）

今回はOracleからAmazonRDSデータベースへの移行例、またその際にMySQLと Auroraについての特徴と利点などを比較下セッションです。

タイトルと目次

タイトル：(ISM304) Oracle to Amazon RDS MySQL & Aurora: How Gallup Made the Move (弊社訳：OracleからAmazonRDS MySQLまたはAmazon Auroraへの移行：Gullup社の事例) 目次：・Gullup社の紹介・当初の課題・なぜAWSだったか？・データベース以外の事情についての考察・RDS MySQLの利点と課題・移行後のアーキテクチャ・DevOps ・Amazon RDSとAmazon Aurora ・まとめ

Gullup社の紹介

（※ 以下、スライドの要約）

（割愛します。詳細はこちら）

当初の課題

本セッションにおける問題。オンプレで抱えるよくある問題たち

本セッションにおいては具体的に下記のようなもの。・スケーラブルな調査分析プラットフォームを準備したい・コストは最適化されている必要がある・分析のための豊富なキャパシティ・高可用性（24x7 HA) ・レプリケーション・複数リージョンでのデータ分離・隔離・簡便な管理方法

なぜAWSだったか？

AWSの採用理由について。おおきく５つの理由から

コスト最適化 ※ 従来のモデルでは。。・ソフトウェアライセンスコストが前払いで発生・ハードウェア投資の発生・ハードウェアとデータベースの二重管理の負担
複数リージョンのサポート・Patriot Act(米国愛国者法): 取り扱う情報（世論統計など）の性質から準拠する必要がある(?)。すみません、背景は勉強不足です。とにかく複数リージョンでデータを抱える必要性の一つということですね。・国境を超えたデータ転送
高可用性・レプリケーション
スケーラビリティ・ピークロード、スパイクに対応可能となるAutoScaling ・分析処理による負荷・バッチの実処理時間によるもの・継続的な負荷とはならない
豊富なマネージドシステム体系・RDS, EMR, Redshift, S3, KMS ... etc.

データベース以外の事情についての考察

クラウド移行にあたって、データの処理操作以外で考察すべき要件。大きく、「プロセス」と「テクニカル」要素について

プロセス

オンプレミス・固定されたプロセスの存在・10年にわたって最適化されてきたものがある・伴って受け継がれてきた運用管理の負荷
クラウド・新しいプロセスへの切り替え・新しいツールセットへの切り替え・文化を変える（データを自社設備におくものではない、という考え方）・データ隔離
データマイグレーション・VPC とpublic ・帯域（自社ネットワークからVPNを経由したVPCへのアクセス・セキュアなデータ移行を実現する必要がある・暗号化・データベース・ETL(Extract , Transform , Load)

テクニカル

リソースの変化＝スキルセットのギャップが発生・MySQLのプロシージャや関数の経験が必要となる・AWSのスキルセット・サービスレイヤのマインドセット（http,web,...etc) ・Oracleのスキルは軽便なものでよくなる(?) ・結果として、多くの欠乏と特化が発生(?)
データマイグレーション・データ同期の要件・オンプレミスとクラウドの比較・自動化 - 構築費と購入費・Amazon RDS reporting repository ・Data lake ・S3のデータ貯蔵性（統合性とグローバル）・アドホックなカスタムデータ作成や分析処理・クロスドメインでのデータ分析を容易にする・AWSに関する留意点・SQS: 「いわゆるqueueではない」こと・S3: 結果整合性(Eventual Consistency) ・各種AWSサービスにレイテンシとパフォーマンスがあること

RDS MySQLの利点と課題

Oracleから載せ替えをする上でのRDS MySQLについての考察

RDS MySQLを使用することで得られる恩恵

・リレーショナルDB（Oracle代替としての）・コスト効率がよく、管理が簡単・スケーラブル・リサイズがシームレスに可能・読み込み用DBインスタンス・スケーラビリティ ※ 大多数が読み込みとなる（レポートのため）・一時的な要求となる・レプリケーションとHA ※ マルチregion, KMS , ... etc ・セキュリティと暗号化

データ移行時の課題

データベース・プロシージャ内のカーソルパラメータ・動的SQL: 即時性がもとめられる・デバッグとログ保管・動的SQLに伴うカーソル宣言・Global temporary table ・FROM条件内のサブクエリこれらの機能移行
データインテグレーション・HTTPエンドポイント（SNS）・メール通知能力・S3への統合・SQSへの統合(enqueue/dequeue)

移行後のアーキテクチャ

構成について。

移行後の構成

RDS MySQL ・現データのレポート・広範囲で使用されるストアドルーティンやプロシージャ
RDS++ ・DBプロシージャとのAWS側での統合・XMLベースの定義・Javaアプリケーション
レポート用の構成・Tomcat/Java ・VPC / EC2 / ELB / AutoScaling
データ用の構成・Tomcat/Java ・ETL / SWS(AWS?) / S3 / SQS / AWS java SDK / RDS++Host
分散コンテクストのマネジメント・ElastiCache
データ収集・SQS / S3 ・ETL / S3 : 既存オンプレミス環境で処理された統計データ
オンプレ環境の構成・Tomcat/Java ・ETL / S3 / CLI (VPN経由でVPCにアクセス）・共有ディレクトリにOracleからエクスポート

MySQL移行時に必要となったワークアラウンド

(※スライド割愛します。19から22枚目まで) ・変数のスコープ・ストアドプロシージャ間で共有するセッション変数・動的SQLのカーソル・一時テーブルを作成する・一時テーブルに移した動的SQLを実行

移行後のMySQL

・400以上のプロシージャ(初期フェーズ）・200以上のテーブルとビュー（初期フェーズ）・オンプレミスからの統計データをサポート・レポート機能をサポート・Amazon RDS++ ・SQS / S3 / SNS / SES をMySQLからサポート・一部のプロシージャを統合

DevOps

・GitHub ・オンプレ環境で使用（VPN経由）・Jenkins ・Javaのデプロイ・DBコード（プロシージャ）デプロイ・Ec2とChef ・AutoScalingに対応・Stress Environment(?) (プロダクション環境のクローン）・デプロイの自動化・マルチリージョンに対応・S3を中継したデプロイステップ

オンプレ：Jenkins - チェックアウト
jenkins - warファイルをビルドし、適切なバケットにデプロイ
jenkins - QA-EC2(図を参照)にてスクリプトを実行し、ファイルsync
PROD-EC2 にデプロイを実行（スクリプト）
AutoScaling - AutoScalingで追加されるインスタンスは以下の手順を踏む・インスタンス作成・インストールとデプロイ・warファイルをS3からsync ・完了後、ELBに追加

Amazon RDSとAmazon Aurora

Auroraの採用にあたって

・早期採用・読み込みインスタンス増大と遅延時間の短縮・レプリケーションとHA ・将来的なAWSコンポーネントとの統合性・将来的なDevOpsツールの拡充。特にデータベースのデプロイにおいて・暗号化 ★ ロールアウトのためには、この機能拡充を待っている

まとめ

本セッションのまとめ

AWSは将来にわたって私たちにフィットしている・コスト効率性に対して・スケーラビリティ対して・挑戦的で全体的なビジネスニーズの発生に対して
RDS MySQLとAurora ・コスト効率の良いOracle代替となる。クラウド上において。特にアプリケーション面、パフォーマンス面でのスケール性によって・Auroraに関しては、将来的なAWSコンポーネントとの統合性も期待できる

さいごに

OracleからAWS RDSへの移行例を紹介するセッションでした。移行によって何を実現したいか、それをどのようにして構成に落とし込んだか、さらには移行にあたっての留意点や課題となった点について、スライドにわかりやすくまとめられていて、勉強になりました。オンプレ環境からのAWS移行を検討するにあたって参考となるセッションかと思います。

それではー。